Improved handling of --time-limit when combined with -J
authorJoey Hess <joeyh@joeyh.name>
Thu, 22 Sep 2022 16:47:40 +0000 (12:47 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 22 Sep 2022 16:54:52 +0000 (12:54 -0400)
commit66bd4f80b34815f2cef4b144d72184fb40d8ec79
treef40e16ab8f2355c8342497d522306b13dc77e3f9
parent6f0566d7047d2ffa802aef325327b1dac24464be
Improved handling of --time-limit when combined with -J

When concurrency is enabled, there can be worker threads still running
when the time limit is checked. Exiting right there does not
give those threads time to finish what they're doing. Instead, the seeking
is wrapped up, and git-annex then shuts down cleanly.

The whole point of --time-limit existing, rather than using timeout(1)
when running git-annex is to let git-annex finish the action(s) it is
working on when the time limit is reached, and shut down cleanly.

I noticed this problem when investigating why restagePointerFile might
not have run after get/drop of an unlocked file. With --time-limit -J,
a worker thread may have finished updating a work tree file, and be killed
by the time limit check before it can run restagePointerFile. So despite
--time-limit running the shutdown actions, the work tree file didn't get
restaged.

Sponsored-by: Dartmouth College's DANDI project
Annex.hs
CHANGELOG
CmdLine/Action.hs
CmdLine/Seek.hs
doc/git-annex-common-options.mdwn